This will not work for cars without ZEVPreconditioningType.now support. (Some EQVs and Smarts) these cars have to use ZEVPreconditioningType.immediate

I checked the capabilities lists and we can check if the capability "precondNow" is False and "ZEV_PRECONDITIONING_START" is True. When this is the case then we have to call the client. preheat_start_immediate(...) function.

Thanks for the clarification. I'll work out a plan and keep you posted.

I am currently doing the final touches. I hope to push the first update this evening.

Hey @ReneNulschDE, Spoiler alert: this PR got a bit bigger than expected! :)

The new flexibility we’re aiming for, where we can dynamically swap the behavior of switches at runtime, led me to create new configuration classes. These classes make it super easy and flexible to define new switches and their behavior when toggling them on or off. This configuration pattern could also be extended to other entities.

async def async_turn_on_preheat(self: MercedesMESwitch, **kwargs) -> None:
    """Turn on preheat."""
    if self._car.features.get("precondNow"):
        await self._coordinator.client.preheat_start(self._vin)
    else:
        await self._coordinator.client.preheat_start_immediate(self._vin)


SWITCH_CONFIGS: list[MercedesMeSwitchEntityConfig] = [
    MercedesMeSwitchEntityConfig(
        id="preheat",
        entity_name="Preclimate",
        feature_name="precond",
        object_name="precondStatus",
        attribute_name="value",
        icon="mdi:hvac",
        capability_check=lambda car: check_capabilities(
            car, ["ZEV_PRECONDITIONING_START", "ZEV_PRECONDITIONING_STOP"]
        ),
        turn_on=async_turn_on_preheat,
        turn_off=lambda self, **kwargs: self._coordinator.client.preheat_stop(self._vin),
    ),
    MercedesMeSwitchEntityConfig(
        id="auxheat",
        entity_name="Auxiliary Heating",
        feature_name="auxheat",
        object_name="auxheatActive",
        attribute_name="value",
        icon="mdi:hvac",
        capability_check=lambda car: check_capabilities(
            car, ["AUXHEAT_START", "AUXHEAT_STOP"]
        ),
        turn_on=lambda self, **kwargs: self._coordinator.client.auxheat_start(self._vin),
        turn_off=lambda self, **kwargs: self._coordinator.client.auxheat_stop(self._vin),
    ),
]

If you're happy with this new approach, I'm happy to migrate the other entities to this pattern as well. With this new concept, adding new functionality is much simpler. For instance, we can now pass enumeration values for sensor entities, which wasn’t possible with the previous approach using positional parameters.

However, there's one drawback: due to cyclic dependencies, we can no longer keep the entity objects or configurations in the Const file. So now we have two options: either we completely restructure the modules to allow for central management again, or (my preferred option) we keep the configs in their respective files—Switch configs in the Switch file, Sensor configs in the Sensor file, and so on.

Let me know what you think!

Yeah :-) Very good – I planned the change to this approach about two years ago but never found the energy to do it. As this aligns with the standard HA approach, I fully support it. However, let us start with the switch, roll out a release, and check what comes up. Additionally, I want a release before October 17, as I expect some changes in the Auth Stack from the MB team... (The Auth Stack is the critical path of this component...) Let me review it and test with some cars in my test fleet.

Tests are successful. Thanks. 👍

I’d like to further refine the data classes. What does your timeline or release schedule look like?

Best would be to have a release latest on Saturday morning.